Telegram Group & Telegram Channel
Универсальный стек для работы без Docker Compose

Удивительное рядом. Как оказалось, многие разработчики зашли в разработку когда в их проекте уже был Docker Compose и они не видели других способов работы. Когда-то я рассказывал как перейти на Docker Compose, а теперь пришла пора говорить о том, как работать без него :)

Docker Compose, в первую очередь, нужен для унификации среды разработки, чтобы сетап был единым независимо от того, где вы его разворачиваете и что там на машине было установлено. Как ни странно, все это было и до него, например через Vagrant (Кто еще застал разработку через него?). Переход на Compose произошел из-за повального движения в сторону легковестных контейнеров, а не полноценных виртуальных машин. К тому же Docker становился стандартом в продакшене, что давало возможность переиспользовать Dockerfile для разработки и продакшена. Но реальная жизнь оказалась сложнее. По порядку:

1. Единый Dockerfile для продакшена и девелопмента это миф и работает только в примитивных случаях
2. Постоянные сложности с настройкой сервисов, так как работа внутри контейнера часто требует особой конфигурации, запуска в хедлес режимах и указания специальных переменных окружений.
3. Compose значительно усложняет процесс разработки: внутри/снаружи, установка зависимостей, персистентность (игра с волюмами).
4. Compose требует шаманств в работе с редактором. Чтобы заставить работать lsp сервера и линтеры, нужно научить их ходить во внутрь контейнера, либо как-то имитировать идентичный сетап снаружи.

В итоге решая буквально одноразовую задачу по первоначальному сетапу, Compose значительно ухудшает сам процесс разработки, с которым мы сталкиваемся каждый день. Можно ли отказаться от него, не потеряв те преимущества, которые он дал? На 100% нельзя, но можно сделать достаточно хороший сетап, который уберет большую часть проблем и точно будет намного приятнее в использовании. Что для этого надо?

1. Автоматизация команд с зависимостями. Тут берем Make или его аналог https://www.youtube.com/watch?v=pK9mF5aK05Q
2. Mise - универсальная тулза для установки языков: https://mise.jdx.dev/
3. Overmind: Менеджер процессов, позволяет запускать наборы сервисов как DC: https://github.com/DarthSim/overmind (раньше для этого использовали Foreman, формат кстати остался тот же)
4. Как ни странно тот же Docker. Например не имеет смысл ставить базу прямо в систему, ее можно запускать так же в контейнере, но без Compose

Все это можно подсмотреть в нашем продакшен проекте https://github.com/hexlet-basics/hexlet-basics/blob/main/Makefile

Что еще? Пожалуй главная засада это первоначальная настройка вашей операционки. В маке что-то надо поставить через brew, в ubuntu через apt. Но опять же, решается все это крайне просто через тот же Make:


macos-setup:
brew install overmind caddy


Но даже в этом случае, подготовить сетап не сложнее чем написать docker-compose.yml (в реальности последний написать сложнее, если это связано с конфигурацией сервисов под работу внутри контейнеров). А вот использование будет на порядок проще.

Ссылки: Телеграм | Youtube | VK



tg-me.com/orgprog/317
Create:
Last Update:

Универсальный стек для работы без Docker Compose

Удивительное рядом. Как оказалось, многие разработчики зашли в разработку когда в их проекте уже был Docker Compose и они не видели других способов работы. Когда-то я рассказывал как перейти на Docker Compose, а теперь пришла пора говорить о том, как работать без него :)

Docker Compose, в первую очередь, нужен для унификации среды разработки, чтобы сетап был единым независимо от того, где вы его разворачиваете и что там на машине было установлено. Как ни странно, все это было и до него, например через Vagrant (Кто еще застал разработку через него?). Переход на Compose произошел из-за повального движения в сторону легковестных контейнеров, а не полноценных виртуальных машин. К тому же Docker становился стандартом в продакшене, что давало возможность переиспользовать Dockerfile для разработки и продакшена. Но реальная жизнь оказалась сложнее. По порядку:

1. Единый Dockerfile для продакшена и девелопмента это миф и работает только в примитивных случаях
2. Постоянные сложности с настройкой сервисов, так как работа внутри контейнера часто требует особой конфигурации, запуска в хедлес режимах и указания специальных переменных окружений.
3. Compose значительно усложняет процесс разработки: внутри/снаружи, установка зависимостей, персистентность (игра с волюмами).
4. Compose требует шаманств в работе с редактором. Чтобы заставить работать lsp сервера и линтеры, нужно научить их ходить во внутрь контейнера, либо как-то имитировать идентичный сетап снаружи.

В итоге решая буквально одноразовую задачу по первоначальному сетапу, Compose значительно ухудшает сам процесс разработки, с которым мы сталкиваемся каждый день. Можно ли отказаться от него, не потеряв те преимущества, которые он дал? На 100% нельзя, но можно сделать достаточно хороший сетап, который уберет большую часть проблем и точно будет намного приятнее в использовании. Что для этого надо?

1. Автоматизация команд с зависимостями. Тут берем Make или его аналог https://www.youtube.com/watch?v=pK9mF5aK05Q
2. Mise - универсальная тулза для установки языков: https://mise.jdx.dev/
3. Overmind: Менеджер процессов, позволяет запускать наборы сервисов как DC: https://github.com/DarthSim/overmind (раньше для этого использовали Foreman, формат кстати остался тот же)
4. Как ни странно тот же Docker. Например не имеет смысл ставить базу прямо в систему, ее можно запускать так же в контейнере, но без Compose

Все это можно подсмотреть в нашем продакшен проекте https://github.com/hexlet-basics/hexlet-basics/blob/main/Makefile

Что еще? Пожалуй главная засада это первоначальная настройка вашей операционки. В маке что-то надо поставить через brew, в ubuntu через apt. Но опять же, решается все это крайне просто через тот же Make:


macos-setup:
brew install overmind caddy


Но даже в этом случае, подготовить сетап не сложнее чем написать docker-compose.yml (в реальности последний написать сложнее, если это связано с конфигурацией сервисов под работу внутри контейнеров). А вот использование будет на порядок проще.

Ссылки: Телеграм | Youtube | VK

BY Организованное программирование | Кирилл Мокевнин


Warning: Undefined variable $i in /var/www/tg-me/post.php on line 283

Share with your friend now:
tg-me.com/orgprog/317

View MORE
Open in Telegram


Организованное программирование | Кирилл Мокевнин Telegram | DID YOU KNOW?

Date: |

Should You Buy Bitcoin?

In general, many financial experts support their clients’ desire to buy cryptocurrency, but they don’t recommend it unless clients express interest. “The biggest concern for us is if someone wants to invest in crypto and the investment they choose doesn’t do well, and then all of a sudden they can’t send their kids to college,” says Ian Harvey, a certified financial planner (CFP) in New York City. “Then it wasn’t worth the risk.” The speculative nature of cryptocurrency leads some planners to recommend it for clients’ “side” investments. “Some call it a Vegas account,” says Scott Hammel, a CFP in Dallas. “Let’s keep this away from our real long-term perspective, make sure it doesn’t become too large a portion of your portfolio.” In a very real sense, Bitcoin is like a single stock, and advisors wouldn’t recommend putting a sizable part of your portfolio into any one company. At most, planners suggest putting no more than 1% to 10% into Bitcoin if you’re passionate about it. “If it was one stock, you would never allocate any significant portion of your portfolio to it,” Hammel says.

Importantly, that investor viewpoint is not new. It cycles in when conditions are right (and vice versa). It also brings the ineffective warnings of an overpriced market with it.Looking toward a good 2022 stock market, there is no apparent reason to expect these issues to change.

Организованное программирование | Кирилл Мокевнин from ms


Telegram Организованное программирование | Кирилл Мокевнин
FROM USA